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[57] ABSTRACT 

A mapping between an object model and a relational data- 
base is generated to facilitate access to the relational data- 
base. The object model can be created from database schema 
or database schema can be created from the object model. 
Further, the mapping can be automatically generated. The 
Database schema, object model and mapping are employed 
to provide interface objects that are utilized by a runtime 
engine to facilitate access to the relational database by object 
oriented software applications. 

18 Claims, 6 Drawing Sheets 
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OBJECT MODEL MAPPING AND RUNTIME 
ENGINE FOR EMPLOYING RELATIONAL 
DATABASE WITH OBJECT ORIENTED 
SOFTWARE 

5 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

A claim of priority is made to US. Provisional Patent 
Application Serial No. 60/069,157, entitled TIER 3 
DESIGN SPECIFICATION, filed Dec. 9, 1997 and incor- 
porated herein by reference; and US. Provisional Patent 
Application Serial No. 60/059,939, entitled DATABASE 
SYSTEM ARCHITECTURE, filed Sep. 26, 1997 and incor- 
porated herein by reference. 15 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 
N/A. 

BACKGROUND OF THE INVENTION 20 

The present invention is generally related to database 
technology, and more particularly to interfacing object ori- 
ented software applications with relational databases. 

The need for interfacing object oriented software appli- 25 
cations with relational databases is well known. One method 
of interfacing an object oriented application with a relational 
database is to adapt the requests made by the application to 
the relational database. More particularly, object operations 
are translated into relational database queries. However, this 30 
technique is processor-intensive and sacrifices some of the 
advantages associated with the object oriented model. As a 
result, the object oriented software application is unable to 
function efficiently. 

Another method of interfacing an object oriented appli- 35 
cation with a relational database is to translate database 
information into a format which is compatible with the 
object oriented application. Relational databases typically 
separate data into a plurality of tables through a process 
known as "normalization** to minimize duplication. A nor- 40 
malized relational database includes a plurality of tables, 
wherein each table includes at least one field and one key, 
and at least one field in each table is uniquely dependent 
upon the key that is associated with the table. These tables 
can be translated into objects. However, the objects can 45 
become inaccurate when changes are made to the relational 
database. It is known to adapt to changes in the relational 
database by performing further translations, but this process 
requires substantial effort. ^ 

BRIEF SUMMARY OF THE INVENTION 

In accordance with the present invention, a mapping 
between an object model and a relational database and a 
runtime engine are employed to facilitate access to a rela- 55 
tional database. The object model can be created from 
database schema or database schema can be created from the 
object model. Further, the mapping can be automatically 
generated. The database schema, object model, and mapping 
are employed to provide interface objects that are utilized by 60 
an object oriented software application to access the rela- 
tional database. 

The present invention provides transparent access to the 
relational database. The interface objects and runtime engine 
perform read and write operations on the database, including 65 
generation of SQL code. Consequently, neither program- 
mers nor software applications need have knowledge of the 



database structure, the database programming interface, 
database security, or the database transaction model in order 
to obtain access to the relational database. Further, changes 
to the relational database do not always necessitate addi- 
tional mapping. 

BRIEF DESCRIPTION OF THE DRAWING 

Other features and advantages of the present invention 
will become apparent in light of the following detailed 
description of the drawing, in conjunction with the drawing, 
of which: 

FIG. 1 is a block diagram that illustrates use of the map 
to generate interface objects that are employed by a runtime 
engine and an object oriented software application to access 
a relational database; 

FIG. 2 is a block diagram of database schema; 

FIG. 3 is a block diagram of an object model; 

FIG. 4 is an object diagram of a mapping; 

FIG. 5 is an object diagram of the runtime engine; 

FIG. 6 is an object diagram of RtCore.DLL; and 

FIG. 7 is a sequence diagram that illustrates operation of 
the runtime engine. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring to FIG. 1, a mapping tool 10 is employed to 
generate a map 12 in which relationships between an object 
model 14 and schema associated with a relational database 
16 are defined. A code generator 18 is employed to examine 
the relationships that are defined in the map 12 and a model 
object oriented interface associated with an object oriented 
software application 22 to generate interface objects 20. The 
interface objects 20 are employed by the object oriented 
software application 22 to access the relational database 16 
via a runtime engine 24, which also uses the map 12 to drive 
its processing. 

The object model 14 is a template that has a predeter- 
mined standardized structure. The illustrated object model 
includes attributes and inheritance relationships that are 
mapped to relational database features such as tables, rows, 
columns, keys, and foreign keys. Mapping the object model 
to the relational database schema includes mapping a class 
attribute to a table column, mapping a class attribute to a 1-1, 
1-N, or N-N relationship, and mapping class inheritance to 
rows within a table or across tables. 

Referring now to FIGS. 2, 3 and 4, the mapping of a class 
attribute to a table column can be described generally as: 
Class Attribute-*Tablc Column+Class Key+Joins. Mapping 
the class attribute defines where the attributes are read from 
and written to. In the illustrated example, the class attribute 
CPerson.name 26 maps to table column TPerson.name 28. 
The "Class Key" is employed to relate an object instance to 
a row in the table. In particular, key values of the class are 
mapped to columns in a table that comprise the primary key. 
In the illustrated example, CPerson.id 30 maps to TPerson id 
32. "Joins" defines keys between tables within a class. Since 
there is only one table in the mapping of Cperson.name to 
Tperson.name, no information is required for Joins. If Cper- 
son includes two tables, such as Tperson and X, then 
mapping Cperson.y to X.y includes: Cperson.y Maps to 
X.y+Cperson.id Keys to Tpersonid+Tperson.id Joins to 
X.idL 

Mapping a class attribute to a 1-1, 1-N, or N-N relation- 
ship with at least one other object can be described generally 
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as: Class Attribute -*Class+Class Attribute-*Foreign Key+ 
Joins. When an object has associations to other objects, an 
attribute in the object points to one or multiple other objects. 
If the object points to only one object, there is a one-to-one 
(1-1) association between the objects. If an object points to 
multiple objects, there is either a one-to-many (1-N) or 
many-to-many (N-N) relationship between the objects. In 
the illustrated example, CEmployee.dept 34 maps to Cde- 
partmeDt 36, where CEmployee 38 to CDepartment 36 is a 
one to one relationship. "Foreign Key" represents identify- 
ing the foreign key. If CEmployee is related to CDepartment, 
there is a foreign key to another table. The foreign key is 
identified within one of the tables that comprise Cemployee 
and is related to the class attribute Cemployee .dept This 
relationship may be inferred from foreign key information in 
the database schema. It is also possible that foreign key 
information is missing or that there are many foreign keys in 
CEmployee to CDept. Consequently, this step involves 
selecting columns that represent the foreign key. In the 
illustrated example, Cemployee .dept is associated with 
TEmployee.deptid. Once a class attribute is associated with 
the foreign key which resides in that class, "Joins" is defined 
to associated classes. In the illustrated example, TEmploy- 
ee.deptid joins to TDepartment.id is defined. 

Mapping class inheritance to rows within a table or across 
tables is performed by specifying a WHERE clause on the 
class which can distinguish the class from the associated 
parent class. This information is stored in the mapping 
model. 

Table 1 describes how an object model can be mapped to 
structures in a database schema. 



TABLE 1-conUnued 



TABLE 1 



In object model: Gin be mapped to: 



A 6 ingle class All or selected columns in a table, A WHERE 
clause can be associated with a class to 
specify which rows of the table belong to the 
class. 

Multiple tables that are joined by the same 
primary key, or by a unique foreign key 
relationship. If the same data is stored in 
multiple tables, the duplicate columns can be 
handled by mapping one of the table columns 
for read, and all of the columns for insert 
and update. 

Multiple tables, possibly in different 
databases, which have similar column 
definitions (e.g., EastEmployees and 
WestEmployees tables can be merged as a single 
Employees class). 

Multiple tables that are unrelated in the 
database, if a logical relationship can be 
defined in the mapping. 
Single inherited A single denormalized table. Columns that 
classes contain data for all records are typically 

mapped to the superclass, and a WHERE clause 
is defined for each subclass as a 
discriminator for selecting which rows belong 
to the given subclass. 

Multiple tables that have the same primary 
keys. To ensure uniqueness of records, the 
primary keys of "subclass" tables may also be 
defined as foreign keys for the "superclass" 
table. 

Multiple A single denormalized table. Different 

inherited classes columns are mapped to each of the classes. 

Typically, there arc multiple columns that can 
be used as indexes. The subclass mapping has 
multiple joins defined, which are used to 
traverse each of the inheritance 
relationships. 



In object model: Can be mapped to: 



10 



15 



20 



25 



Multiple indexed tables. The table that is 
mapped to the subclass has multiple keys 
corresponding to each of the keys in the 
superclass tables. To ensure uniqueness of 
records in the subclass table, the key on the 
subclass table may not be defined as a multi- 
column key. If all the data of the superclass 
tables is duplicated in the subclass table, 
then no join is required to instantiate an 
instance of the subclass. However, joins 
would be needed to ensure integrity of data 
when performing insert, remove, and update 
operations. 



Object relationships are mapped to the database schema 
by defining the joins needed to access related objects or 
groups of objects (lists). The joins make use of foreign keys 
defined in the tables that are mapped to the related classes. 
T^ble 2 describes mapping of object relationships relative to 
the illustrated example. 

TABLE 2 



30 



Object 
Relationship: 



Mapping Example: 



35 



40 



50 



55 



60 



1-1 object Department can have only one Manager, 

relationship Department class has an object attribute (Manager) 

that references only one instance of the Employee 

class. 

Department table has a foreign key column 
(ManagerlD) that references only one row in the 
Employee table. A join is defined for the Department 
class based on a unique foreign key. 
N-l object Many Employees have one Department, 

relationship The Employee class has an object attribute 

(Department) that references one instance of the 
Department class. 

The Employee table has a foreign key column 
(DeptID) that references one row in the Department 
table. A join is defined for the employee class to 
access the one row in the Department table that is 
referenced by the foreign key in the Employee 
table. 

1-N object A Department has many Employees. . 

relationship The Department class has a list attribute (Employees) 

that references the related group of employees. 
Employee table has a non-unique foreign key that 
references the Department table. A join is defined 
for the Department class that selects all rows in 
Employee that matches the current 
Department's Deptid 
N-N object An Employee can have many Projects. A project can 

relationship have many Employees. 

Employee class has a list attribute that 
references a group of Projects, and the Project class 
has a list attribute that references a group of 
Employees. 

This mapping uses joins based on the join table that 
relates the Employee table and the Project table. The 
Employee class uses a join to select rows from the 
Project table that match the current instance's 
Employee id. The project class uses a join to select 
rows from the Employee table that match the current 
instance's Projcctid. 



65 



Table 3 describes how structures in a database schema can 
be mapped to structures in an object model. 
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TABLE 3 



Id a database 
schema: 



Can be mapped to: 



A single table 



Rows, discriminated All attributes of a single class 
by WHERE dause 

All attributes of a class, assuming the other 
persistent attributes of the class arc mapped to 
columns in other tables. 
Multiple classes (effectively, a vertical split 
of the table) 

A single-inherited classes (if at least one 
column is appropriate for discriminating 
selection of rows for subclasses) 
Multiple-inherited classes (if the table has 
multiple indexes) 

A single class (if the key structure exists to 
join row uniquely) 

Multiple classes (unrelated, unless key structure 
exists to support joins) 

A single class that represents a logical merge of 
the tables. (NOTE: Primary key values must be 
unique between the tables.) 
Single inherited classes (each table represents a 
class, keys used to define joins between subclass 
tables and superclass table, 
single class (with joins based on primary key) 



Multiple tables, 
different columns 



Multiple table, 
same columns 

Multiple tables, 
same primary key 



binary file is generated in parallel with each DLL containing 
the mapping information associated with the DLL The 
RtMap.dll 50 implements the classes that can load the 
information from the binary file at runtime and make it 
5 available to the runtime interface objects associated with 
DLLs 56 and to the client objects 58 of the generated COM 
objects through a set of predefined COM interfaces. 

Classes OOBase and OObject in RtCore.dll 52 form the 
core of the runtime engine 24. The OOBase is a base abstract 
10 class which is used as a base for all the generated imple- 
mentation classes. The generated classes are ATL COM 
objects implementing one of the standard IDslObject/ 
IDslList/IDslQlist and one or more of the client interfaces 
(e.g., Employee). The ATL implementation classes have 
15 state implemented as a set of attributes of the primitive types 
called the "front state" (or the front data set). The OOBase 
contains a pointer to the OObject and a public pure virtual 
method to access the address of each attribute in the classes 
descending from itself. Hie attributes are indexed according 
20 to the class definition for the object. The OObject class is 
abstracting the runtime functionality for a generic object It 
contains a set of attribute info-value pairs (one per attribute, 
constructed when the object is initialized to form a "back 
state," or baseline). OObject also has a set of attribute flags 
25 (one per attribute, bitwise or of values like isModified, 
isRetrieved, isDirty, isNull and others). One instance of the 
OObject is created for every instance of the generated 
objects to take care of the interface to the persistent data 
storage through a set of DB objects that are MTS stateless, 



If the same data is stored in multiple tables, the duplicate 
columns can be handled by mapping one of the table .col- 
umns for read, and all of the columns for insert and update. 

Schema relationships are mapped directly to object 
relationships, either in the form of object attributes or list 30 transactional (objects. 

attributes. In general, a foreign key in the database schema nG 7 mustates me sequence of actions that take place 
is mapped to an inverse relationship between an object wnen a business object creates a Dsl object in step 61, 
attribute (on the class mapped to the table holding a foreign accesS es the name property in step 65 and saves the object 
key) and a list attribute (on the class mapped to the table m step 69 OObject is constructed when the constructor of 
referenced by a foreign key). A join table is mapped to an 35 ^ DPefSon (the generated COM implementation class) is 



inverse relationship between list attributes defined on each 
of the classes mapped to the tables related by the join table. 

Table 4 describes bow relational keys are mapped to 
object relationships relative to the illustrated example. 

TABLE 4 



40 



Schema 
Relationship 



Corresponding Object Relationship 



Unique 
Foreign Key 



Non- Unique 
Foreign Key 



Join Table (with 
no other 
data columns) 



Join Table (with 
additional data 
columns) 



1-only-l object relationship represented by 
an object attribute with a cardinality of 
one on the class mapped to the table that 
has the foreign key. This relationship can 
also be mapped as an embedded type. 
N-l object relationship, represented by an 
object attribute on the class mapped to the 
table with the foreign key, and a list 
attribute cm the class mapped to the table 
referenced by Ihc foreign key. 
N-N object relationship, represented by a 
list attribute on each of the classes mapped 
to the tables related by the join. Each 
list attribute represents a collection of 
references to objects of the other type. 
A class mapped to the join table, AND a N-N 
object relationship, represented by a list 
attribute on each of the dasses mapped to 
the tables related to the join, 



45 



50 



55 



60 



Referring to FIGS. 5 and 6, the runtime engine comprises 
a plurality of dynamic link libraries ("DLLs**) including: 
RtMap.dll 50, RtCore.dll 52, DbObjs.dll 54, OiGenBase.dll 
57, and a set of generated DLLs 56. The generated DLLs 56 65 
contain one COM interface and implementation class for 
each class defined by a mapping model. A mapping model 



invoked in step 62. The constructor passes as parameters the 
appropriate constant Classlnfo reference and a reference to 
itself. The OOBject initializes all flags and sets the attributes 
to the default values as defined in the Attrlnfo objects 
associated with the Classlnfo in step 63. The GetAttrPtr( ) 
function defined by the OOBase is employed to get the 
attribute address for each attribute in the class in order to 
initialize the front set of attributes on the object in step 64. 

When the getName (propget) of the generated object is 
called in step 65, the generated code checks to see if the 
attribute was retrieved. If the attribute was retrieved then the 
cached value is returned. Otherwise, RetrieveAttrValue( ) of 
the OObject is called in step 66, passing the id of the desired 
attribute (name in the example). The OObject will look at the 
fetch matrix for this attribute and see what other attributes 
should be retrieved with it in step 67 and then determines 
what tables and columns are involved, how they are joined 
and executes the appropriate SQL statements using the 
stateless MTS object. The GetAttrPtr( ) function denned by 
the OOBase is employed to get the attribute address for each 
attribute in the class in step 68. 

When the object is saved in step 69, the generated code 
calls the OObject SaveChange( ) method in step 70. The 
OObject determines what attributes have changed and, 
depending on the concurrency control mode in effect, makes 
sure the appropriate locks and transactions are set and 
respectively open and then executes the appropriate SQL to 
write the data to the persistent storage in step 71. 

Referring again to FIGS. 1-4, the runtime engine also 
includes a plurality of performance enhancing features such 
as optimized data retrieval algorithms. An attribute retrieval 
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can be associated with each attribute to optimize attribute utilizing a runtime engine which invokes said at least one 

retrieval from the database. As a default case, all attributes interface object with the object oriented application to 

are retrieved when any one of an object's attributes arc access data from the relational database, 

needed. However, the attribute retrieval list for any attribute 2 . The method of claim 1 further including the step of 

can be edited to specify different attribute retrieval behavior. 5 ^ a dass tQ a taWe ^ 

£t^ 3 - v ™r ^ 1 * step of 

on the Id attribute if that data resides in another table and is ™PP™Z a class attnbute to a w relationship, 

only infrequendy used. Attribute retrieval lists are a perfor- 4 ^ method of claim 1 further including the step of 

mance feature that enable optimized data access by only mapping a class attribute to a l-N relationship, where N is 

doing JOINS and additional SELECT statements when the 10 an integer that is greater than 1. 

data returned by those actions is needed. 5. The method of claim 1 further including the step of 

Performance is also enhanced by "just in time" data mapping a class attribute to an N-N relationship, where N is 

retrieval. By default, whenever an attribute value is read a n integer that is greater than 1. 

from the database, all of the other attributes for that instance 6. The mc thod of claim 1 further including the step of 

are also read. However, Data Component Developers are mapping class inheritance to rows within a table, 

permitted to modify the mapping information for a Data ? ^ method of claim x mcludm ^ ^ st of 

Component to define an attnbute retrieval group for each . , . . . , ~ ° , , t r 

attribute of a class that determines which other attribute m ^ class inheritance across a phirahty of tables, 

values are returned when the requested attribute is read from 8 - The method of claun 1 furtber deluding the step of 

the database. This makes it possible to avoid executing 20 creating a plurality of said interface objects, 

JOINs or SELECTS to retrieve data that may not be needed. 9. The method of claim 8 further including the step of 

For example, assume that a class, CPerson, has four creating at least one stateful interface object and at least one 

attributes: Id, Name, Zip, and Photo, and the Photo attribute stateless interface object. 

is mapped to a column in a different table from the others. 10. A computer program fixed on a computer-readable 

The Data Component Developer may drop Photo from the 25 medium and adapted to operate on a computer to provide 

group of attributes that are retrieved when either Id, Name access tQ a relational database for an object oriented ^ 

or Zip are read- A query is issued to get the Name and Id of wafe UcatioQ> OTmprising: 

a instance of CPerson where Id=«10. Based on the attnbute * r — & 

retrieval information, the run time engine retrieves only the a mapping routine that generates a map of at least some 

values for the person.id, person.name, and person.zip 30 relaUonships between schema in the database and a 

attributes, thus avoiding an unnecessary join to return the selected object model; 

photo attribute value as welL a code generator that employs said map to create at least 

If an object does not have an attribute in memory when an one interface object associated with an object cone- 

attempt is made to use that attribute, the object will issue a sponding to a class associated with the object oriented 

SELECT statement to retrieve the attribute from the data- 35 software application; and 

base. "Just-in-time" attribute population allows the object to a engine that mvokes at least one interface 

be populated with the minimal amount of information nec- ^ to aocess data from me relational database 

essary for the apphcaUon while still making any remaining n ^ of claim 10 whcrcin ^ mapp i n g 

information available when it is needed. . . , *u * * V ui 

, routine is operative to map a class attribute to a table 

Lazy reads are also employed to enhance runtime perfor- 40 

mance When a query is defined to 'identify objects for u ^ of claim 10 wherein ^ m 

retneval from the database, the SQL SELECT statement is routme 1S operative to map a dass attributc to a 1A rela . 

not issued immediately. Queries are executed only after an tionshin 

attempt has been made to use or modify the resulting data. 13 ^ e program of claim 10 wherein said mapping 

Having described the embodiments consistent with the 45 routine ^ operative to map a attribute to a 1-N 

present invention, other embodiments and variations con- relationship, where N is an integer that is greater than 1. 

sistent with the present invention will be apparent to those 14 prograni of io wherein said mapping 

skilled in the art. Therefore, the invention should not be routinc ^ operauve to map a ^ attribute to an N-N 

viewed as limited to the disclosed ernbodiments but rather relationship, where N is an integer that is greater than 1. 

should be viewed as limited only by the spirit and scope of 50 15 ^ program of claim 10 wherein said mapping 

the appended claims. routine is operative to map class inheritance to rows within 

What is claimed is: a ta D i e> 

1. A method for interfacing an object oriented software 16 xh e program of claim 10 wherein said mapping 

application with a relational database, comprising the steps routine is operauve to map class inheritance across a plu- 

of: 55 rality of tables. 

selecting an object model; 17, The program of claim 10 wherein said code generator 

generating a map of at least some relationships between is operative to create a plurality of said interface objects, 

schema in the database and the selected object model; 18. The program of claim 17 wherein said code generator 

employing the map to create at least one interface object is operative to create at least one stateful interface object and 
associated with an object corresponding to a class 60 at least one stateless interface object, 
associated with the object oriented software applica- 
tion; and ♦ * + + * 
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